天才，出院！

https://lorentz.app/blog-item.html?id=go-shebang

仔细看，第一行并不是一个 shebang，这里利用了 shell 执行命令无视 / 前缀的特性，因此第一行被 sh 执行为 /usr/local/go/bin/go run "script.go" "$@"; exit, 而在 Go 中 // 是 inline comment 被忽略了，使得这一行不影响 Go 的编译和执行

原文底部有对 go fmt 的“兼容”更新。

牛逼，发现某“城市”的“某”银行 600GB 的客户资料、内部文件在网上裸奔。

太草台了。👍👍👍

已尝试上报。

不冷吗？

烂完了，还没修，是想等着哪天上新闻吗？

有什么开源/公益项目缺钱或者缺机器的？

要喝免费旺仔牛奶的，私。

已送。

再次推荐。


uv tool install sshconfig_to_ananta[toml]
uv tool install ananta[speed]

最后还是感觉不对劲，为什么我们要传这么多数据，仔细一看发现全是垃圾，马力全开的话要不了几天数据库就会被塞满垃圾。于是项目停了，打回炉重造。

然后本月则是另一个项目，还是性能问题，跑几十分钟软件就卡住发不出任何请求了。这个倒是简单，开 pprof 等几十分钟后看一下 goroutines，发现全挂在了一个地方，是没有给 tcp dial 设超时。设个超时就修好了。
然后开开心心继续跑，结果又发现 net/http.(*persistConn).writeLoop 和 net/http.(*persistConn).readLoop 一直在缓慢增长并且超过了我们实际正在使用的连接数量。这个太经典了，不就是连接漏了嘛。但是找了一圈也没找到漏的地方，因为泄漏速度非常缓慢，大概百万份连接才泄漏几份？而且创建连接的 goroutine 按照设计，创建之后就早早 return 消失不管连接了，也不知道这些孤儿连接是谁创的。但幸好可以传入 ctx 来直接 cancel 整个请求/连接，所以这个问题也解决了。
推到生产，发现能跑了，性能可以接受，但是无论怎么 scale up scale down，速率只能跑到 5Gbps。

这时候又发现我们的 TCP gateway 上的 tailscaled 发疯了，明明 tailnet 根本没有任何流量，但它却始终在吃单核 100% cpu （流量跑到 4Gbps 时），而且是吃的 kernel 的 cpu 时间，我把流量停掉，它就不吃了，开启，它又开始了。虽然貌似对我们业务没影响，但好不爽啊。我一开始怀疑可能是 tailscale 的 tun 跟 iptables/conntrack 可能过滤&追踪包有些 overhead，即使包不是发给 tailscale 的？。但是关了 tailscale 的包过滤和改iptables，都没效果。然后一跑 perf，好家伙，tailscale 的 Services List (Port List) 功能每秒会读一次 /proc/net/tcp、/proc/net/tcp6、/proc/net/udp、/proc/net/udp6。我们的连接太多了，kernel 甚至无法在一秒内返回这些 /proc/net/* 。还好 tailscale 这个功能可以关掉，关掉就好了。
参考：https://github.com/tailscale/tailscale/issues/10430

然后还是卡在 4Gbps 过不去。各种 profile + trace + 乱猜 + 改配置 + 换网卡，鼓捣了一周，今天我们最终终于找到了原因……昨天其实我就非常接近原因，但是我很怀疑啊，感觉不可能，同事之前说那块性能非常非常棒所以几乎不可能出问题的。
今天同事对那块加了 32 台杜甫来处理……非常完美啊，终于达到 10Gbps 了。

才高兴了一小时，我们又注意到请求成功率大幅下降，甚至跌破了之前的 4Gbps 时的成功率。不过这时候的问题已经与技术无关了……

我嘞个 JDBC 啊，先进。

如何检验别人的 Go 代码是否是 vibe 的。
ctrl+s，看 import 的顺序有没有变化。

哇塞，哭了啊，完全是给房东打工。税后工资，房东一半我一半，不多不少刚刚好。😭

终于关了存储桶的访问。工商银行“太厉害”了。